We would need to change the regression workflow to find the unit test binaries somewhere else. It's simpler if you add a meson option to skip installing them by default, and then we can install them in the regression test script.

Thanks! I'll have a look!

But... The documentation indicates the unit tests should be run from within the build dir (https://su2code.github.io/docs_v7/Running-Unit-Tests/). Shouldn't the regressions test script do the same, then?

(I'm not an SU2 pro... Maybe the regression test script tests for more and/or other things, which would invalidate the above.)

I see, there are multiple tests being run:

• UnitTests/test_driver{,_AD,_DD}
• TestCases/...

The former currently relies on hardcoded paths in the source tree, which typically only work in the build container and test container. The hardcoded paths break the unit tests in any other situation.

My patches remove the hardcoded paths, and instead tell Meson to move the files to the build tree. This makes the unit tests work as documented.

Of course, the files can be installed as well. The test_driver then needs to be run from the right dir, or needs to have correct paths hardcoded into it. In the latter case, the documentation needs an update: only run the tests after installing.

So, there are three options:

1. Do nothing: the documentation should be changed to reflect that the unit tests will generally not work, unless run under very specific circumstances.
2. Remove hardcoded paths, do not install unit tests, run unit tests at build time. This is how it is documented, and how most other software does it.
3. Remove hardcoded paths, install unit tests, at test time go to correct work dir and run unit tests. Documentation needs an update too.
4. Have build system insert hardcoded paths to $prefix, install unit tests, run unit tests at test time. Documentation needs an update too.

3 and 4 would break things like EasyBuild, that assume tests are run before installation, and require an update to the documentation.

2 seems like the right option.

What do you think?

Option 2 would require a change to the compileSU2.sh script. I doubt that that will be reflected anytime soon, which results in the tests failing until the container is updated.

@pcarruscag I think options 3 above is what you suggested, but would still either break the documented way to run unit tests (ninja -C builddir test), or require one to specify a workdir in regression.yml, which seems impossible.

What is the intention of tests? Should they be run before installing, to ensure one doesn't install a broken binary, or should they be run after installing?